       ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                 September, 1988  *
         *        *                                                  *
        *         *                              Volume 3, Number 3  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                *******                           *
       * * *      *               *********                          *
       * **       *               **     **                          *
                  *                      **                          *
           *      *                 *******  *********               *
           *      *                ******    *********               *
       ******     *               **         **                      *
           *      *               *********  **                      *
           *      *               *********   *******                *
                  *                                 **               *
       ********   *                *******   **     **               *
             *    *               *********  *********               *
            *     *               **     **   *******                *
           *      *                      **                          *
            *     *                 *******  *********               *
             *    *                ******    *********               *
       ********   *               **         **                      *
                  *               *********  **                      *
        ***       *               *********   *******                *
       *   *      *                                 **               *
       *   *      *                *******   **     **               *
       *   *      *               *********  *********               *
        ***       *               **     **   *******                *
                  *                      **                          *
       ******     *                 *******  *********               *
           *      *                ******    *********               *
           *      *               **         **                      *
           *      *               *********  **                      *
       ****       *               *********   *******                *
                  *                                 **               *
           *      *                *******   **     **               *
           *      *               *********  *********               *
       ******     *               **     **   *******                *
           *      *                      **                          *
           *      *                 *******  *********               *
                  *                ******    *********               *
       ********   *               **         **                      *
           *      *               *********  **                      *
           *      *               *********   *******                *
           *      *                                 **               *
       ****        **************************************************

1


             *     *              *     *                   *
             **    *         *    **   **       *       *   *
             * *   *  ***  *****  * * * *  ***  ****  ***** ****
             *  *  * *   *   *    *  *  * *   * *   *   *   *   *
             *   * * *****   *    *     * *   * *   *   *   *   *
             *    ** *       *    *     * *   * *   *   *   *   *
             *     *  ****   *    *     *  ***  *   *   *   *   *
       ******                                                    ******


       Christopher Condon    Editor                   CONDON @ YALEVM
       Timothy Stephen       Associate Editor        STEPHEN @ RPICICGE
       Craig White           Associate Editor         CWHITE @ UA1VM
       June Genis            Contributing Editor      GA.JRG @ STANFORD
       David Hibler          Contributing Editor    ENGL0333 @ UNLVM
       Henry Mensch          Contributing Editor       HENRY @ MITVMA
       Deba Patnaik          Contributing Editor        DEBA @ UMDC
       Gerry Santoro         Contributing Editor         GMS @ PSUVM
       Marc Shannon          Helpdesk Editor        HELPDESK @ DRYCAS
       Glen Overby           Technical Assistant    NU070156 @ NDSUVM1
       Gary Moss             Point of View              MOSS @ YALEVM


       ********************* Contents - Issue 25 *********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       Flames To: .................................................. 3
       An EARN-Poland Link ......................................... 5

       FEATURES_______________________________________________________

       The White Pages for Albany .................................. 8
       Using IDSERVER .............................................. 9
       Exchanging Mail Among Usenet, BITNET, and FidoNet .......... 11

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 17
       Feedback ................................................... 20
       Policies ................................................... 24


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *


       -----------------------------------------
1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  CONDON@YALEVM
        *********


                            "We learn by doing."


       I hid  her notebook.   In retrospect  I suppose it was  a silly
       thing to do,  but we learned a lot from it.   She was a bright,
       intelligent Co-op student  who made my grade point average look
       like  burned  waffles.    I  was  the  Co-op  student  she  was
       replacing.   As such, I was given the task of passing knowledge
       to a person obviously more intelligent than me.  Worse, she was
       a snappy dresser.

       She had a  little stenography notebook that  she carried around
       during her  training period,  and  she would write  down almost
       everything I  said and did.    When it  came time to  perform a
       particular task,  she would flip to the appropriate page in the
       notebook and  follow the instructions  therein.   When  she ran
       into trouble  she would call me  over to help her.    She would
       then add whatever I did to her instructions.

       I began to  wonder whether she was really  learning anything at
       all.   The whole idea of working as  a Co-op was to gain a kind
       of knowledge and  experience that one can't get  from reading a
       book or taking a test.   This was a reasonable facsimile of the
       real world of computers,  with all of its delights and dangers.
       Somehow this Co-op  was taking this experience  and reducing it
       back to the textbook (in this case, notebook) level.

       So I hid the notebook and asked her to perform some task.   She
       of course protested that she couldn't do it without a reference
       of some kind.   I suggested that there  was a real rush on this
       particular item, and that she had better hurry.

       It took her a little longer to reach her goal, but when she was
       done she  had a  better understanding of  the software  we were
       using.  It wasn't a matter of pressing F1, typing "A", pressing
       Control-Q and  so on.    If the  commands were  changed or  the
       software was different,   she now knew that she  had the mental
       tools to *figure it out*.
1

                                                                Page 2


       This is true every time a new  user begins using the network to
       communicate.    The  concepts of  electronic  mail,   messages,
       mailing lists, and forums become real tools and challenges, not
       words and pictures in a book.    When a student passes from the
       world  of  education  to  the world  of  business,   they  will
       inevitably be  faced with  other networks  and other  software.
       After BITNET,   however,  many  of these  people will  have the
       ability to use these tools and use them effectively.

       The benefits of  exposure to BITNET vary from user  to user and
       from discipline  to discipline.   The  key to  maximizing these
       benefits is education and training.    Handing someone a userid
       and a copy  of BITNET USERHELP is  a nice idea,  but  it hardly
       matches the payback of sitting  people at terminals and saying,
       "Do it."   Watch them  receive mail and  send messages  to each
       other.  The concepts come to life before their eyes.  Suddenly,
       the network isn't a burden, but a tool to be used.  It can even
       be fun.

       When they understand this,  give them real examples of how they
       can get the  most out of the  network.   If you are  training a
       psychology  class,   give  them  information  on  the  Psychnet
       magazine  and  server.    If you  are  teaching  Communications
       majors,  show them COMSERVE and CRTNET.   Then let them explore
       and find other services and topics to thrill and amaze them.

       The value of BITNET isn't just  in the information and services
       that these students receive today.   It is in the understanding
       and abilities they will take with  them when they are no longer
       part of this network.


                       Virtually,

                            Chris Condon@YALEVM
1

                                                                Page 3


        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  University of Alabama
       *         *
       *         *  CWHITE@UA1VM
        *********


       Hello everyone,

       I have been hopelessly behind this month. I hope your month was
       slower.   Around here it's time for  the students to return for
       the fall semester and things are really hopping.  I have gotten
       a ton of  mail this month and  at one point I  just deleted the
       whole lot and got a fresh start with an empty in-box.   From my
       perspective,  the network seemed to be down more than it was up
       this month.    I would go for  days without receiving  a single
       piece of mail,  and then very  suddenly many files would arrive
       all at  once.   I really think  that this is a  serious problem
       with BITNET but that's a flame for another day.

       This month's  flame is  about the sending  of large  files over
       BITNET.   I understand that under  some circumstances sending a
       large file is unavoidable.  A reason that comes to mind is when
       the information is  needed quickly and there's  not enough time
       for a tape,  granted that the time variable is very subjective.
       From my  experience,  those  who attempt to  send or  receive a
       large file,  are  generally new to BITNET.    Usually they know
       nothing about networking and the concept of a limit on the size
       of your files comes as a shock.

       At least twice in the past month I have had people who were new
       to networking either  trying to send large files  or waiting on
       files to arrive  that were way over the 300K  limit.   The ones
       who were trying to send the files were the easiest to deal with
       because they were local.   The ones  that were on the receiving
       end of a large file were more  difficult to deal with.   It was
       obvious to  me that  the files  had been  put on  hold or  even
       purged at some point along the way.

       I've found  that nine  times out  of ten  when I  start hearing
       things like "What is  taking my file so long to  get here?" or,
       "Do you think my  file got lost?",  it's time to  ask about the
       size of the file.   Most of the time,  the file is in fact over
       the limit and I go into a standard BITSEND/BITRCV talk with the
       user.
1
                                                                Page 4


       Now for the flame, when a file is put on hold or purged because
       of size problems,  both the SENDER  and the RECIPIENT should be
       notified of this fact and, in addition, both should be informed
       as to  where they  can get  BITSEND/BITRECV.   Some  people may
       argue  that only  the sender  should  be notified  or only  the
       recipient.   My reasoning  for both is that most  files are not
       unsolicited,  both parties have probably  discussed the file in
       question and  reached a decision  that the recipient  needs the
       file.   Because of this,  they both  should have a good idea of
       the size of the file.   If this is the case,  and the file gets
       sent anyway,  then  both people should be told the  fate of the
       file.

       Winding down,  I think that the  sending of large files is done
       mainly  by uninformed  users of  the network,   and purging  or
       putting the file on hold without  any notification of this fact
       is  cruel.   If  it  was  the US  Postal  Service  it would  be
       criminal.  At the very least notification should be sent to one
       of the  parties.   Optimally,  the  file sending  program would
       check the size of  the file and BITSEND it if  necessary ,  but
       that is just too much to expect right now.

       Finally,  LDBASE.COM for VAX sites is now available.   It is in
       the tools filelist  at a LISTSERV near you.   To  obtain a copy
       you  could  use  the  LISTSERV command  GET  LDBASE  COM  TOOLS
       FILELIST.  I understand that it is written in FORTRAN and comes
       with everything you need to get it up and running.   As always,
       questions, comments and flames to CWHITE@UA1VM.
1

                                                                Page 5


        *********
       *         *  An EARN-Poland Link
       *         *
       *         *  by Dave Phillips, et al.
       *         *
       *         *  State University of New York at Buffalo
       *         *
       *         *  V184GAVW@UBVMSA
        *********


       A May,   1988 NetMonth article  proposing an  academic computer
       link to the USSR spawned a  series of discussions,  a couple of
       which surfaced in subsequent issues of this publication.

       Since June a discussion group  has formed,  comprised of Polish
       graduate students studying in the West,  Western scientists who
       have worked in  Poland and/or who have  Polish colleagues,  and
       others  on the  network  who are  familiar  with the  potential
       scientific and cultural benefits offered by a link between EARN
       and  Polish  universities.    The private  list  is  small  but
       growing, and extends from Vancouver to Lund, Sweden.

       This group has as its purpose to identify the problems involved
       in establishing such a link, and to elaborate the benefits, and
       to place a developed proposal before  EARN and some of the more
       autonomous institutions in Poland.

       From John  Duchowski,  4th year  PhD student,   Carnegie Mellon
       University, originally from Warsaw:

       "Being a chemist,  I fully appreciate the need for rapid access
       to information.   The advent of  Chemical Abstracts On-Line has
       greatly simplified and improved  the usual literature searching
       methods.   However,  personal communications between scientists
       in  the West  and  the East  still have  to  rely on  sometimes
       lengthy standard mailing procedures.   At  present,  we in 'the
       West' have only a limited  access to 'Eastern' publications and
       vice versa.   Providing an EARN link  could be set up,  both of
       these problems would be alleviated.

       "Historically,  since the end of World  War II,  people on both
       sides  of the  'iron  curtain' have  also  been drifting  apart
       culturally.   Open  discussions on subjects other  than science
       are few  and far between.    Access to  electronic discussions,
       such as RELAY, would also lead to a greater and presumably more
       open minded exchange of cultural viewpoints.  Idealistic as all
       this sounds, and where the initial discussions on subjects such
       as history may be heated,  with time the differences on certain
       issues may become of purely  academic interest.   This would of
       course lead to the decrease in tension between the two sides.
1

                                                                Page 6


       "Finally,  from a purely social point of view,  the benefits of
       open communication are particularly easy to see.  Although this
       may  be looked  upon as  a glorified  'pen pal'  aspect of  the
       Electronic  Mail,  the  free  exchange  of ideas  and  opinions
       between  private   citizens  on  both   sides  should   not  be
       underestimated.

       "The above comments apply equally  well to any Eastern European
       country.  Nothing  has been said thus  far about why  the first
       candidate for a BITNET connection  should be Poland.   Being of
       Polish origin,  I may indeed be accused  of some kind of a bias
       in  that direction.    From a  historical perspective  however,
       Poland has always been a  very western-oriented country.   Even
       as a  member of  Soviet bloc Poland  probably enjoys  the least
       controlled society, vis a vis Bulgaria or even Hungary,  albeit
       at the expense of a ruined economy.  Therefore, an EARN link to
       Poland would  probably be under  a lesser degree  of government
       control as compared to other Soviet bloc countries.

       "We also have  to consider the drawbacks on  equal footing with
       the benefits.    The most  obvious is the  sad state  of Polish
       economy.   To maintain a good  quality telephone line in Poland
       is far from cheap and frequent  breakdowns should be taken into
       account.   Moreover, the cost of EARN  membership,  yet another
       drain of badly needed Western currency,  may not be seen as one
       of the first priorities by  the Polish government.   Also,  the
       existence  (or  lack  of  it)   of  a  sufficiently  up-to-date
       technical base,   such as mainframe  computers,  may  limit the
       number of candidate sites.   Another  question that needs to be
       asked is how is the access to the EARN-linked computer going to
       be  controlled.     Even  minimal  (by  East   Bloc  standards)
       government  control  might invalidate  the  benefits  mentioned
       above."

       From Andrew Duchowski, Simon Fraser University:

       "I  just  learned  recently  from a  friend  of  mine  here  in
       Vancouver  of  another  example  of  potential  for  scientific
       exchange.   Biochemistry at several educational institutions in
       Poland is at a fairly close level to some research institutions
       here in Canada.  Specifically, protein purification research is
       one such  example.   With an EARN  link,  this research  may be
       assisted by  the use of  information exchange between  the East
       and West. "

       From David Phillips, SUNY at Buffalo:

       "The  benefits  to the  world  outside  the Soviet  bloc  would
       outweigh any  real or imagined  risks incurred  in establishing
       such  a  link,   particularly  if that  link  is  connecting  a
       relatively independent society like Poland's.
1

                                                                Page 7


       "Although Poles suffer official censorship,  a pervasive secret
       police  and laws  similar  to those  in  the  USSR,  there  are
       thousands  of underground  publications,   a legal  independent
       Church, private agriculture, and the East bloc's first and only
       independent trade union federation, NSZZ Solidarnosc,  which is
       an affiliate  of both the  International Confederation  of Free
       Trade Unions and  the World Confederation of  Labor.   There is
       literally a  world of difference between  Poland - even  in its
       present state of  collapse - and Soviet society at  the peak of
       its "glasnost."  This  difference has been maintained  at great
       cost by the Poles since 1944.

       "There  is also  a  thriving  independent student  movement  in
       Poland,   and thus  there is  a strong  possibility (though  no
       guarantee)  of making an EARN-Poland link,  should it ever come
       about,  a genuine link -  not a vacuum cleaner attachment for a
       Bloc  information  gathering  apparatus   rationed  to  trusted
       apparatchiks.

       "The problems are at four levels:   1)   Faculty,  students and
       administrators  at   the  more   autonomous  universities   and
       polytechnics in Poland  have to be made aware  of the potential
       for a link  and of our support  for such a venture;   they will
       request it once it appears possible, of this (viz. the students
       at least) we're certain.  2) EARN must decide in principle that
       such a link, if requested, is OK;  this involves in part EARN's
       members' relationship with  the US government,  which  leads to
       3)  the assessment by the US  government of the relative merits
       versus risks  in acquiescing  to a  positive decision  by EARN.
       Finally,  there are  4)  the technical problems of a first link
       itself,   involving site  selection,   phone  line,  money  and
       institutional commitment.

       "The perception  of the  US government would  seem to  hinge on
       concerns of technology leakage  and perhaps potential sabotage.
       How much such a link would expose genuine US security interests
       is hard to say,  but there would seem to be a large and ongoing
       exposure in  the territory  of the USA  itself (from  East Bloc
       diplomatic personnel,  intelligence  gatherers,  communications
       monitoring, illicit export of hardware).

       "Finally,  we  cannot guess  in advance  whether the  regime in
       Warsaw will accept requests from schools for a link; this would
       depend  in  part  on  their  perception  of  the  international
       climate."


       John Duchowski   -   Pittsburgh   (jd3a+%andrew.cmu.edu@CMCCVB)
       Andrew Duchowski -   Vancouver    (USERQP4C@SFU)
       David Phillips   -   Buffalo      (V184GAVW@UBVMSA)
1

                                                                Page 8


        *********
       *         *  The White Pages for Albany
       *         *
       *         *  by Deba Patnaik
       *         *
       *         *  University of Maryland
       *         *
       *         *  DEBA@UMDC
        *********


       WHOIS@ALBNYVM1 is an  online white pages for  the University at
       Albany.  It  accepts commands by  both interactive  message and
       electronic mail.   If  you send a command by mail  it should be
       places on the Subject line or on  the first line of the message
       area.

       Your command, as such,  is the last name of the person for whom
       you you are looking.   For example, to look for people with the
       last name  of "Jones" you would  send the command  JONES.   The
       response would look much like this:

            Name: Jones, Arthur; Phone: (518)442-1234;
              Office: Service Bldg A 904B; E-mail: none

            Name: Jones, Heidi; Phone: (518)442-1001;
              Office: Social Sciences 290; E-mail: HUGGA@ALBNY1VX

       If you are unsure of a spelling, wildcards are allowed, as long
       as they are preceded by two characters.   For example, a search
       for S* is invalid, but a search for SM* would work:

            Name: Smirensky, Hubert; Phone: (518)442-7717;
              Office: Library A23A; E-mail: none

            Name: Smith, Wayne; Phone: (518)442-5290;
              Office: Service Bldg A; E-mail: WAYNE@ALBNYVM1

       If the server  can not find a  match for your search,   it will
       respond with names that sound much like it.   In this example I
       was searching for the name TOMAS:

            Name not found.  Possibly similar name(s) are:

            Name: Thomas, Andrew; Phone: (518)442-1623;
              Office: Earth Sciences 132F; E-mail: none

            Name: Tomaski, Herb; Phone: (518)442-1158;
              Office: Computing Svcs 05; E-mail: HERB@ALBNY1VX
1

                                                                Page 9


        *********
       *         *  Using IDSERVER
       *         *
       *         *  by Gerry Santoro and Chris Sacksteder
       *         *
       *         *  Pennsylvania State University
       *         *
       *         *  GMS@PSUVM and CJS@PSUVM
        *********


       IDSERVER@PSUVM is a service machine that  looks up the name and
       userid of persons with accounts on  node PSUVM.   You send it a
       message containing either a name or userid.   It's main purpose
       is to provide PSUVM userids to BITNET users.

       If a  person is not found  that does not necessarily  mean they
       are not at Penn State or are not joined to a system operated by
       another department and accessible via e-mail.   Student accouts
       expire  at the  end of  every semester  and are  given only  to
       students taking course requiring mainframe use.   Also, not all
       faculty and staff have accounts on PSUVM.

       USING IDSERVER:

       IDSERVER  accepts  interactive  messages only.    Mail  is  not
       accepted at this time.   For example,   on an IBM VM/CMS system
       connected to BITNET,   a command to send a  message to IDSERVER
       would be of the form:

            TELL IDSERVER AT PSUVM  (

       Users on DEC VMS/JNET systems would use this syntax:

            SEND IDSERVER@PSUVM  (

       The  may be the following,   and may be abbreviated to
       the shortest form shown in upper case:

       Userid  - search string is a userid (synonyms: Id, Initials) as
       opposed to a last name

       ANy - match any part of the name, not just the last name

       Campus  - also show campus where user is located


       * Examples of searches:  Names and userids  do not  have  to be
       sent in uppercase.

       SMITH            find users with the last name SMITH
1

                                                               Page 10


       SMITH DAVID      find users with the last name SMITH, and first
                        name DAVID.

       SMITH RICHARD B  find user RICHARD B SMITH.

       SMYT*            find users with last name starting with SMYT.

       DXS  (USERID     find userid DXS.


       SMITH (C         find  users  named  SMITH,  and  list the  PSU
                        campuses where they are registered or working.

       TOM (ANY         find users with TOM in any part of their name.


       * Capbilities  and Limitations:   The  IDSERVER simply  runs an
       end-user command  called FINDUSER,   collects the  output,  and
       returns it  to the  requestor.   The  FINDUSER EXEC  depends on
       several local  fixed-format data files,   and is  therefore not
       very portable.

       The number of  records returned is currently limited  to 20 for
       network users.  That is, only the first 20 matches are returned
       to the  requestor.   If  there are  too many  occurrances of  a
       particular  last name,   add the  first  name as  shown in  the
       examples above.
1

                                                               Page 11


        *********
       *         *  Exchanging Mail Among Usenet, BITNET, and FidoNet
       *         *
       *         *  by Chris Graham
       *         *
       *         *  Guest Writer from Usenet
       *         *
       *         *  moore!graham!chris@uunet.uu.net
        *********


       This  article describes  the use  of  gateways between  Usenet,
       BITNET and FidoNet,  especially within the Canadian province of
       Ontario.   Using  techniques described here  it is  possible to
       send  mail from  an  academic computing  account  on BITNET  to
       someone far  away who  does not  have access  to any  medium or
       large computer system (such as relatives  in one's home town or
       other far-away place, or a penpal).   Conversely,  this article
       contains techniques which  can be used,  by people  who have no
       access to large  or medium sized computer systems  to send mail
       to individuals who  have BITNET accounts.   And  the best thing
       about mailing  from BITNET  to the  other destinations  is that
       it's free.   The reverse route can be free in some cases and if
       it isn't, the cost is very low.

       The  way  the  above  can  be achieved  is  by  making  use  of
       communication  links  between BITNET  and  various  independent
       bulletin  board systems  (BBSs).   A  BBS is  a small  computer
       (usually some sort of IBM compatible) which is connected to the
       telephone system and maintained by its owner as a hobby.   BBSs
       run software, such as Fido and Opus, which allow other computer
       owners to log into them over the phone, by means of a modem and
       quite ordinary  telecommunications software.    Once a  user is
       logged into a BBS, he may exchange mail with other users of the
       BBS.   And he may transfer files and programs from his computer
       to the BBS for other users,  or pick up files and programs that
       other users have left in the BBS.   In most cities,  there is a
       plentiful abundance  of BBSs,   and access to  most of  them is
       free.   Some BBSs  are members of a network,   designed for and
       populated  by BBSs,   called FidoNet.    On  BBSs connected  to
       FidoNet, it's possible to exchange mail, not only with users of
       the same BBS,  but with users of other BBSs on the network,  in
       much the  same way  as this  can be  done with  BITNET.   Since
       membership in FidoNet is popular  among operators of BBSs,  and
       since it's  possible to route mail  from BITNET to  FidoNet and
       vice versa, it is likely that,  within any town or city,  a BBS
       may be found which will facilitate communication between a user
       on BITNET and  any individual within that town or  city who has
       access to a microcomputer or terminal and a modem.
1

                                                               Page 12


       The  method used  to accomplish  the above  is to  make use  of
       gateways  which mediate  between BITNET  and  Usenet (which  is
       another  network)  and  other  gateways  which mediate  between
       Usenet and FidoNet.   In this way, a third network is used as a
       path between FidoNet  and BITNET in much the same  way a string
       is used between two tin cans.    This may sound complicated but
       the  rest  of  this  article will  show  how  simple  this  is.
       Incidentally, some individuals have access to computers because
       of their employment and it's  possible that these computers are
       linked  to  Usenet.    Literally  thousands  of  computers  are
       connected  to  Usenet,   including those  of  AT&T,   Commodore
       Business Machines and others.   If  someone works for a company
       which has a computer that's linked to Usenet and the individual
       in question has access to that computer, then the techniques of
       this article may be used in order to exchange mail between that
       person and people on either  BITNET or FidoNet.   Communicating
       between Usenet and  BITNET is free and sending  mail to FidoNet
       is free but sending from FidoNet  to either BITNET or Usenet is
       free or costs very little.

       Gateways  are computers  which  are connected  to  two or  more
       networks and allow  information to be routed from  sites on one
       network to sites on another.   For example,  if a sender has an
       account on a BITNET site and he addresses mail to a destination
       on Usenet,  that  mail will be routed through  a computer which
       resides on  both networks  so that  it can  be conveyed  to the
       network  which  contains  the  destination  site.    Using  the
       information  presented in  this  article,   it is  possible  to
       reliably route mail from sites on FidoNet, through Usenet,  and
       on to a site on BITNET.   Likewise, techniques for the converse
       movement of mail will be presented within this article.  A lack
       of details  about more  than one  Fido/Usenet gateway  prevents
       this article from explaining precisely how, but it will provide
       a general  framework of how gateways  may also be used  to move
       mail between  FidoNet  sites  in a  way  that  minimizes  long-
       distance telephone fees.    This can be accomplished  by moving
       the mail  through Usenet and  back to  a FidoNet nearer  to the
       destination.

       While FidoNet sites telephone each other directly, Usenet sites
       pass  mail to  intermediate  sites like  a  team of  messengers
       relaying a message.  For example, if a Fido site in Toronto has
       mail aimed at a site in Washington D.C.,  the Toronto site will
       incur long-distance charges by  telephoning the Washington site
       directly.   In contrast,   a Usenet site in  the same situation
       will figure out the path of least cost using other Usenet sites
       along the way.   In this way, the mail would be passed along by
       several different sites on its way  to the destination and each
       intermediate site would only have to  place a local call.   Not
       only is this  an advantage in saving on  long-distance but it's
       also how Usenet sites get mail to other sites to which they are
1

                                                               Page 13


       not connected; such mail is bounced around the network until it
       reaches a  site which  is.   This  is why  addresses on  Usenet
       sometimes take a form like  "moore!graham!chris".   Such a form
       is called a bang-path and this particular example is understood
       to mean that  the mail is routed  to a site called  moore which
       then passes  it on to another  site called graham,   which then
       passes the  mail to chris  (which graham  knows as one  of it's
       users so it gets to the user and goes no further).  If moore is
       not directly  connected to the site  which is first  to receive
       mail so addressed, it will use a smart mailer program to figure
       out the path of  least cost so that it can be  passed as far as
       moore.   Because of smart mailers,   it's possible for a Usenet
       address  to  be  as  short  as  chris@graham  or  graham!chris.
       However,  such addresses will fail on  sites which do not run a
       smart mailer or if the site (graham)  is not known to the smart
       mailer program.   At  this point,  it should  be mentioned that
       upper-case characters should not ordinarily  appear in a Usenet
       address; doing so can cause mail not to be delivered.

       FidoNet  addresses are  much simpler  but  harder to  remember.
       They are in  a form such as "chris graham  ON 223/228".   Here,
       "chris graham" is  the login name of the  target individual and
       223/228 is  the designation of  the destination site.    If the
       destination site is in a  different region than the originating
       site, then an additional region number must be specified in the
       destination  address as  in 1:223/228.    This  is not  usually
       necessary since all of North America is counted as region 1:  .
       Beyond this,  it's not important to know what the numbers mean;
       any  BBS  connected to  FidoNet  will  make the  right  numbers
       available on request.

       In this  article,  three BITNET/Usenet gateways  are described:
       uunet,  gpu and PSUVAX1.   At  least in Southern Ontario,  mail
       addresses (sent from BITNET) which bear the domain .uucp (as in
       chris@graham.uucp) are routed through PSUVAX1 which is a VAX at
       the University of  Pennsylvania.   Mail can also  be explicitly
       routed through uunet (which is a  major backbone site on Usenet
       in Virginia)   by appending the  suffix "@uunet.uu.net"  to the
       destination Usenet address.   Likewise,  mail can be explicitly
       routed through gpu (which is at  the University of Toronto)  by
       appending    the   suffix    "@gpu.utcs.toronto.edu"   as    in
       "moore!graham!chris@gpu.utcs.toronto.edu".    Since  graham  is
       located in Toronto,  this latter route  is the fastest since it
       allows the mail to  stay in BITNET for more of  the trip.   For
       example,   if a  sender on  BITNET desires  to send  mail to  a
       receiver on Usenet,  and the destination site is graham and the
       destination user's username there is chris, then the sender may
       address   the    mail   to   either    "chris@graham.uucp"   or
       "graham!chris@gpu.utcs.toronto.edu".   In the former case,  the
       mail is routed through PSUVAX1 and in the latter,  it is routed
       through gpu.
1

                                                               Page 14


       In some cases,  PSUVAX1 is a black  hole.   That is to say that
       some mail won't  arrive at its intended Usenet  address and the
       sender won't be notified of the failure.  Such is the case when
       the destination site is unregistered or  it is a new site whose
       registration has not yet been published in the appropriate news
       group and implemented in PSUVAX1.    The logical solution would
       is to  include more  of the destination  path but  PSUVAX1 will
       ignore the extra routing information,  find that it can't route
       the mail  by itself  and dump  the mail  without informing  the
       sender.    In  contrast,  uunet  and  gpu  will adhere  to  the
       destination routing specified by the  user.   For example,  the
       address chris@ziebmef.uucp  will work because ziebmef  is known
       at PSUVAX1 but chris@graham.uucp will fail because, at the time
       of this writing,  graham is a new  site and is not yet known to
       PSUVAX1.  It will seem to work but the mail will fail to arrive
       at  its  destination.    A  reliable way  to  address  mail  to
       chris@graham.uucp is to address it to either

                   moore!graham!chris@gpu.utcs.toronto.edu
                or
                   moore!graham!chris@uunet.uu.net

       Here,  moore is a registered site adjacent to graham and so the
       smart mailer of  either gpu or uunet will route  the message as
       far  as  moore,  and  moore  knows  graham  so it  will  arrive
       reliably.

       In VM (which runs on medium to large IBM systems),  read "@" as
       " at " in the preceding addresses.  It is impossible to specify
       a domain such  as ".utcs.toronto.edu" using JNET  on VAX/VMS as
       in  JNET%"moore!graham!chris@gpu.utcs.toronto.edu".    However,
       IN%"moore!graham!chris@gpu.utcs.toronto.edu" will  work if  the
       necessary  software  is  accessible  on  the  sender's  system;
       otherwise,  VMS will complain of the absence of an .EXE file in
       sys$system: .  In any case, it is required that the sender find
       a means  of specifying  a domain  or the  formula to  gpu won't
       work.

       Going the other way, from Usenet to BITNET is much simpler,  at
       least from a site with a smart mailer; it is simply a matter of
       suffixing ".bitnet" to the  destination address.   For example,
       if "doe"  is the destination site  on BITNET and "john"  is the
       username of  the intended  recipient,  a  sender on  Usenet can
       simply specify  john@doe.bitnet as the destination  address and
       the mail will be automatically routed  to a correct gateway and
       arrive reliably at the destination.

       Two ways are described in this article for addressing mail from
       Usenet to FidoNet.    One way is to specify the  address in the
       form

        firstName_lastName@f.n.z.fidonet.org
1

                                                               Page 15


       For example, if it is desired to send mail from Usenet to Chris
       Graham ON 1:  223/258,  using this method,  then the address to
       use is:

                  chris_graham@f258.n223.z1.fidonet.org.

       The main disadvantage  of this method is that it  can be routed
       through  a  Fido   gateway  that's  very  far   away  from  the
       destination and the gateway has to make a long-distance call to
       the final destination site.   This  doesn't directly affect the
       sender except  that it takes roughly  two more days  to arrive.
       Nevertheless, it is inconsiderate to cause the gateway to incur
       long-distance charges in this way so  it's better all around to
       find a  gateway that's local to  the destination and  route the
       mail through it explicitly.

       That last point brings us to  isishq.   isishq is a Fido/Usenet
       gateway that's connected through the University of Waterloo and
       mail  can be  addressed  to FidoNet  destinations  in the  form
       isishq!network!machine!firstName_lastName.    For example,   to
       send mail  to Chris  Graham ON 223/258  from Usenet  using this
       method,      the     mail     would     be     addressed     to
       isishq!223!258!chris_graham .  If the destination zone is other
       than one,   then another field is  added to the address  as in:
       isishq!1!223!258!chris_graham.   It  should be  added that  the
       sysop of  isishq will  request contributions  if you  cause his
       gateway to incur  too much in long-distance  telephone charges.
       His BBS can dial Waterloo,  Toronto and Montreal rather cheaply
       but if you specify a destination very far away,  it will arrive
       at his gateway  and his gateway will have to  place an outgoing
       telephone call to the destination site.  If you plan to send to
       FidoNet sites outside of the places I've mentioned,  you should
       find a gateway for yourself which is closer to the destination.

       isishq, which is  1:221/162 in FidoNet, will also serve to move
       mail from  FidoNet to destinations  on Usenet.    To accomplish
       this,  go to the net-mail section of  the BBS which is the Fido
       site and  address mail to  uucp on  221/162 (adding the  1:  if
       you're outside that region).  Specify the subject as usual, but
       the first  line of  the message  text must  be the  destination
       address on Usenet  prefixed by "To:  ".   For  example,  if you
       wished to send  mail from a FidoNet  site to chris@graham.uucp,
       you would  address net-mail to uucp  ON 221/162 and  begin your
       message with the line (left justified, of course):

                         To: moore!graham!chris

       Unfortunately,  there is a snag,  which  is the cost of sending
       mail to  221/162 from  another Fido site  when a  long distance
       telephone call is required to do so.  For example, to send mail
       from 223/258 in Toronto, through 221/162 in Waterloo,  requires
1

                                                               Page 16


       that 223/258 place  a long distance telephone  call to 221/162.
       Most  BBSs will  check  an on-line  list  of  FidoNet sites  to
       estimate  what  charges  will  be   incurred  by  the  required
       telephone call and then check to make sure that you have enough
       credit on  balance to  cover the charges.    If the  balance is
       insufficient,  the BBS will refuse  to accept the mail message.
       If  there  is  intent  to  use a  BBS  in  this  manner,   then
       arrangements should be  made with the sysop so  that there will
       be an adequate  credit balance.   Most BBSs in  Toronto seem to
       charge around  35 cents to  route mail through  221/167.   It's
       always best to find and use the gateway closest to the sender's
       (or destination) FidoNet site.

       Because  of the  elegance and  transparency  of the  addressing
       methods of Usenet  and BITNET and the  involved gateways,  it's
       easy to modify the above formulations  in order to address mail
       from BITNET to FidoNet or from FidoNet to BITNET.  For example,
       addressing mail from Chris Graham ON 223/258 to john@doe.bitnet
       is a  simple matter of addressing  net-mail to uucp  ON 221/162
       and specifying "To:  john@doe.bitnet" as  the first line of the
       message text.   Similarly, addressing mail from john@doe.bitnet
       to Chris Graham ON 223/258 is a simple matter of addressing the
       mail   to  isishq!223!258!chris_graham@gpu.utcs.toronto.edu   .
       Both of  these methods  make use  of Usenet  to carry  the mail
       between Fido/Usenet  and Usenet/BITNET gateways,  like  using a
       string to connect two tin cans together.   In a similar manner,
       it should be  possible to use Usenet as the  string between two
       FidoNet sites but that will be left for later.
1

                                                               Page 17


        *********
       *         *  Headlines
       *         *
       *         *  by Chris Condon
       *         *
       *         *  Yale University
       *         *
       *         *  Send your Headlines to BITLIB@YALEVM
        *********


       * King Testifies  before  Senate  Subcommittee (from  Bitnews):
       Kenneth M. King, President of EDUCOM, recently testified before
       the Science,  Technology  and Space Subcommittee of  the United
       States   Senate    Committee   on   Commerce,     Science   and
       Transportation.

       Discussing the formation of a national educational and research
       network,  King  stated that "there  is a broad  consensus among
       government, education,  and industry leaders that creation of a
       high-speed national research and  education computer network is
       a critical national priority."

       The  complete   text  of  the   testimony  is   available  from
       LISTSERV@BITNIC as the file SENATE TESTIMON.


       * BITNET Statistics  (by Hank Nussbacher):   From  a section on
       Wide Area  Networks found in Communications  of the ACM  - July
       1988,  "Fourth Annual  UCLA Survey of Business  School Computer
       Usage":

       "It  appears  from  Table  X  that  BITNET  has  become  almost
       ubiquitous, and that, with an endorsement of 4.0, the users are
       quite satisfied with this capability."

       The table shows that in 1987,   out of 83 business schools that
       replied, 90% had BITNET connection, with the next closest being
       Arpanet (31%).  The numbers for 1985 (42 business schools) were
       67% had a BITNET connection with Arpanet getting 19%.


       * EDUCOM'88 (by Dan Updegrove):   EDUCOM  is gearing up for its
       biggest conference  ever,  October  25-28 in  Washington,  D.C.
       Featured  speakers for  EDUCOM'88,   "Campaign for  Excellence:
       Education, Government, Industry," include Erich Bloch, Director
       of the National  Science Foundation;  Alan Kay,   Apple Fellow,
       Apple Computer, Inc.; H. Ross Perot, Founder of Electronic Data
       systems Corporation; and Edward Redish, Professor of Physics at
       the host University of Maryland.
1

                                                               Page 18


       Program   tracks   include   Emerging   Technology,    Computer
       Networking,   Educational  Software,   Strategic  Planning  for
       Information Technology, Libraries, Social,  Legal,  and Ethical
       Issues, and Management.

       In addition, EDUCOM'88 will feature exhibits of select academic
       software including  this year's winners of  the EDUCOM/NCRIPTAL
       Software Awards; a "playroom" in which conference attendees can
       explore    commercially    available    software;     extensive
       demonstrations by EDUCOM's Corporate  Associates,  and tours of
       capital area campuses and government labs.

       Networking is  the focus  of six  program sessions:   "National
       Networking  Update",   "Conferencing",   "Networking  at  Small
       Colleges",  "Access  to Library  Databases",  "The  New Network
       Applications",   and  "Using  Networks   to  Aid  Collaborative
       Learning."  Network-oriented  Special Interest  Group  meetings
       include "BITNET  in Other Countries",   "Using LANS  to Provide
       Bibliographic Databases to Faculty and Students", and "Networks
       and Electronic Publishing."  There  will also be demonstrations
       of NSFNET, BITNET,  and multi-vendor ethernet connections among
       EDUCOM's Corporate Associates.

       As a  result of the great  demand for information,   EDUCOM has
       posted materials in the articles archive of CCNEWS, a forum for
       campus computing newsletter editors  that uses LISTSERV@BITNIC.
       Four  separate files  are  available,  containing:   Conference
       Brochure,   Conference  Registration  Form,   Conference  Tours
       Information, and Hotel Registration:

                   EDUCOM88 BROCHURE          Lines: 1878
                   EDUCOM88 REGFORM                   181
                   EDUCOM88 TOURS                     322
                   EDUCOM88 HOTEL                     109

       For more information, or to register, contact CONF88@EDUCOM.


       * New BITNET Director (from Mike  Roberts):   I am very pleased
       to announce the appointment of Dr. James B. Conklin Jr.  as the
       new Director of the BITNET Network Information Center.

       Jim  joins  EDUCOM  and  BITNET with  a  strong  background  in
       academic computing.  He most recently was head of the computing
       center  at  the Harvard-Smithsonian  Center  for  Astrophysics.
       Previously,  he was Associate Professor of Physics and Director
       of the  Center for  Instruction and  Research Computing  at the
       University  of Florida  at  Gainesville.    He holds  Bachelor,
       Masters, and Doctoral degrees from M.I.T.
1

                                                               Page 19


       Jim  has  been  an  active  participant  in  BITNET  since  its
       inception  and brings  both experience  and  enthusiasm to  the
       Director's challenging  job.  I know  that he looks  forward to
       working with all BITNET members, small and large,  and would be
       pleased to hear your thoughts on  how to strengthen the network
       and improve the services provided by the BITNIC.


       * BITNET Technical Meeting (by Scott Earley):

            Host:   Harvey Mudd College (BITNET node: YMIR)

            Date:   Saturday, October 15, 1988
            Time:   8:30 am - 6:00 pm
            Where:  Harvey Mudd College
                    260 E. Foothill Blvd
                    Claremont, California
            Free:   Registration and refreshments

       Registering:   If you plan to  go please use LISTSERV@BITNIC to
       SUBSCRIBE to  BITTECH to  facilitate communication.    Staff at
       BITNIC will use the list for  logistics at Harvey Mudd.   Don't
       hesitate  to  use  BITTECH  for  your  own  inquiries,   making
       additions to the agenda and so on.

       Directions  from  Anaheim  and  room  assignments  will  follow
       shortly.  Watch BITTECH for details.

       Objective:    To provide  a forum  for BITNET  users to  become
       involved with  network-related issues and to  develop proposals
       for  submission  to  the  BITNET Board  of  Trustees,   or  its
       Committees.

       Structure:   The meeting opens with  a one-hour Plenary Session
       at 9:00,  after which two Working Groups will break off for the
       rest of  the morning.   Following  lunch the  groups reconvene,
       allowing time for a summary and wrap-up later in the afternoon.

       Plenary:   James Conklin,  Director  BITNET Network Information
       Center.    Jim  will make  a  "state  of the  BITNET  address",
       including progress  of BITNET merging  with CSNET and  the RSCS
       over TCP/IP pilot (BITNET II).

       Parallel Working Group Tracks:   Each  group will report on the
       status  of  recommendations  made  at   the  August  13  BITNET
       Technical Meeting at CUNY Hunter College.   The  working groyps
       are "Being a TECHREP", chaired  by  Jim  Gerland, and "Being an
       INFOREP", chaired by Scott Earley.
1

                                                               Page 20


        *********
       *         *  Feedback
       *         *
       *         *  a Letters Column
       *         *
       *         *  "Something more intriguing..."
       *         *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:      June Genis 
       Subject:   User directory services on BITNET

       The following is in response  to Les's article on NAMESERV@DREW
       in the August  1988 issue of Netmonth,  but  it also summarizes
       some points I brought up at the recent BITTECH meeting.

       Without meaning to  disparage the effort Drew has  made to make
       this service available,   I feel it falls far short  of what is
       needed in directory services for BITNET.  While NAMESERV offers
       an improvement over the old BITSERVE directory in that obsolete
       entries will  automatically expire,   it does  not address  the
       problem of building  critical mass on the entry  side.   It has
       been my experience with all of the servers of this type to date
       that I  can never  really find  anyone I  need in  them because
       those people haven't seen fit to register themselves.

       On the other  hand,  more and more schools  are developing some
       kind of computerized directory for  local use.   Sometimes,  as
       here  at Stanford,   that directory  may be  searchable by  all
       machines  on  a  local  network even  through  it  may  not  be
       accessible via  remote BITNET query.    At other places  it may
       just  be part  of a  batch file  used by  personnel or  student
       records.   But somewhere the critical data is being gathered in
       machine readable  form.   More  importantly,  there  is someone
       whose job  it is at  that institution to  see that the  data is
       keep current, at least on a yearly basis.

       For this reason I would like to see more of the following sorts
       of efforts:

       1.  The  creation of  a registry of  local directories  with an
       indication of  who has access to  it locally,  if there  is any
       network  access  to it,   if  the  owner  would be  willing  to
       contribute  the data  to  a centralized  server  on a  periodic
       basis,  whether  they would be  will to  convert the data  to a
       standardized format  for export to  such a  centralized server,
       and who owns the data and how that person can be contacted.
1

                                                               Page 21


       2.   A lot  more discussion  on  a common  BITNET protocol  for
       directory searches.   By this I mean that no matter what form a
       local directory was stored in, participating institutions could
       create an intermediate server which would translate between the
       common protocol and  the syntactical requirements of  the local
       facility.   End users would then need to know only one protocol
       and the list of nodes which subscribed to it.

       I will post a copy of  this correspondence to the USRDIR-L list
       in the  hope of provoking further  discussion on both  of these
       ideas.

       * Editors note:   I see your  point,  in that getting people to
       register in a name server is terribly difficult.    However,  I
       don't see  the problem  as a  hardware or  software one,   (i.e
       command syntax, local vs. distributed servers, etc.).   To coin
       a cliche, we have a "people problem".

       Assuming that NAMESERV@DREW is a  workable central name server,
       we have two questions:   Why  don't people register themselves,
       and how can we  get them to?   I think this  largely stems from
       the greater problem:   People are uninformed,  there is no true
       users guide, and so on.   We need something that says,  "Step 2
       in becoming a BITNET user:   Register yourself with the central
       name server."

       The alternative is to  require/encourage nodes to automatically
       register their  users with a  central name server.    This,  of
       course,   poses some  software and  cooperation problems,   but
       certainly less than, say, LISTSERV.

       In terms of command syntax and the  plethora thereof,  I object
       to most of them.  If NETSERV can  have a neat full screen query
       (NETNAMES)   I don't  see why  one  couldn't be  written for  a
       central server.

       My objection to a central name  server is the problem of links.
       Once we get everyone  to register,  the server is of  no use if
       people can't access it.  Perhaps yet another mod to LISTSERV...
       nah.


       From:     W. Dean Pesnell 
       Subject:  The Eastern Bloc and Censorship

       The astronomical community  uses BITNET and EARN  to bridge the
       distances and time zones between individuals in the same field.
       At present there are limited connections to Moscow, Warsaw, and
       Budapest to talk to people  at institutions in those countries.
       Increasing the number of nodes is always on their minds and any
       help would be appreciated.
1

                                                               Page 22


       Something  more  intriguing is  the  lack  of access  to  South
       Africa.  Due to the efforts of a single individual in the State
       Department,  mail sent to South Africa  is halted at a European
       node -  not in the USA.   There are other connections  to South
       Africa  that enable  US government  agencies to  talk to  South
       Africa  on   a  more  or   less  daily  basis.    Only  private
       communications are  disabled by  the decision  of this  unnamed
       individual.  Any information as to why US mail can be halted at
       a foreign node would also be appreciated.


       *  Editors  note:    We  received a  number  of  letters  about
       Alejandro  Kurcyns  letter  about  the  potential  problems  of
       linking EARN or BITNET to the Soviet Union.   I think that this
       one sums up the major points nicely:

       From:     Michael Bloom 
       Subject:  The Soviet Union

       Contrary  to  the  assertion  by  Alejandro  Kurczyn  that  the
       Russians don't  want to learn  English ("Let's Bring  BITNET to
       the Soviet Union"),   my impression is that  the Russian people
       are among the most enthusiastic students of our language in the
       world.   English enjoys roughly the same status in Soviet grade
       school and high school curricula as French in this country, and
       there are various indications that their children learn more in
       school than ours.   Moreover,  there is much more incentive for
       the Russians  to continue  to practice  English,  both  because
       English has  become the de facto  trade lingo of the  world and
       because  America still  represents  a  sort of  promised  land.
       (Remember the scene  in the movie "Moscow on  the Hudson" where
       Robin Williams and his friend  the clown practice their English
       by discussing  Hemingway?)   The Voice  of America,   and other
       English-language broadcasts,  offer  anyone who owns a  radio a
       terrific opportunity to  keep up with the  language.   Educated
       Europeans in  general (which the Russians  consider themselves)
       speak several languages as a matter  of course,  given how many
       different countries and native tongues  are in close proximity.
       In contrast,  we  Americans don't feel the  need to accommodate
       anyone else's  speech at  home  (comfortably  far from  French-
       speaking Quebec or  Spanish-speaking Puerto Rico)-- and  I fear
       we've become  so chauvinistic  that we've  grown to  expect the
       rest  of the  world to  adapt  to our  language,  and  culture,
       forever.


       From:     Gershon Kunin 
       Subject:  Listserv Lists

       Over the  last few  months,  the  number of  LISTSERV lists  on
       BITNET has  been on the rise.    In principal,  this is  a good
1

                                                               Page 23


       thing,   and  has  led   to   cooperation  between  people  and
       institutions to  a degree that a  mere three or four  years ago
       couldn't have been imagined.

       But what happens when three or four people each start a list on
       a specific  topic,  without realizing  that there is  already a
       list out there  which handles that topic,  or one  close to it?
       An example  of such  a thing  could be  ADVISE-L and  LIASON-L.
       Both  lists  are  certainly  among  the  most  helpful  on  the
       LISTSERV, but there is redundancy between them.   There's REXX-
       L,   and  a new  list  CMSUG-L  was  just started.    How  much
       repetition can we  expect to see between these  two lists?    A
       person may write to one of the  lists,  and the person with the
       best answer may be subscribed to the other!

       The point that I'm trying to get across is that there should be
       some kind of coordination among  the various lists,  with (more
       or less)  specific topics being set  out for each list.   There
       might  be a  central  clearing house  for  starting new  lists.
       Before a new list is started,   someone should see if this list
       isn't basically another name for an existant list.

       Users should  also know  what lists are  available for  them to
       subscribe.    I  don't  mean  the  LIST GLOBAL  command  that's
       available now,   as it's a  bit too heavy  (1000+lines).   What
       might be more reasonable might be  something like this:  a user
       sends a LIST LISTS command to  the nearest local LISTSERV.   He
       receives a  list of lists  only,  with a  one-line explanation.
       Each list name appears  once.   Such a file might be  150 or so
       lines.  If a user is interested in a  list, he can send a query
       to his local LISTSERV,  asking where  is the nearest server for
       that list (eg. QUERY SERVER ABCDE-L).

       These are  a couple of ideas  that could make the  LISTSERVs on
       BITNET/EARN even more productive for all of us.

       * Editors  note:   If  you are planning  on starting  a mailing
       list, it might be a good idea  to check Rich Zellich's List-of-
       Lists  and LISTSERV  GROUPS to  make your  topic isn't  already
       covered.
1

                                                               Page 24


        *********
       *         *  NetMonth Policies
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  ...but were afraid to ask.
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the command:

            UNSUB NETMONTH

       Internet users may use these methods, but must address the mail
       to LISTSERV@MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       LISTSERV@CMUCCVMA.  For a list of  files,  send the  server the
       the command:

            INDEX NETMONTH

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.
1

                                                               Page 25


       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.

       * Printing this file:  VM  users can print  this file  by using
       the "( CC" option of  the PRINT command.   VAX/VMS users should
       RECEIVE NetMonth  with a  format of  FORTRAN.  This  will allow
       page-breaks to be accepted by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************